Patrick Elliott <sel### [at] rraznet> wrote:
> Huh? How? Your missing the point. The initial structure of the object 
> **must** be static. Why? Because if it isn't, then you have to reparse 
> the entire structure.

  I didn't understand that.

> Currently you can't tell something that you want 
> to add transforms to the 6th nested object in some complex series of 
> unions

  That's a syntax limitation in the current SDL, not a technical one.

> nor can you "change" those.

  It would be possible to change them if the proper syntax would be added.

> The object, once it exists, is static on "all" levels other than the 
> base union.

  It just looks like it for the simple reason that the current SDL has no
syntax for modifying it. AFAIK there isn't any technical limitation to this,
just that the SDL hasn't been enhanced to do this.

> That only gets worse when 
> dealing with a change to the SDL that allows it to run like a program, 

  You mean the current SDL is not "run like a program"? How so?

> If-else blocks won't work because by the time you get to 
> the next frame all of the "code" that contains them will have already 
> executed, and isn't reparsed

  1) If code is not executed at each frame at all, by which method are
you suggesting the user could change some transformations at each frame?

  2) Why do you think the new SDL should have byte-compilation and even
JIT-compilation support? Just for fun? No, for the precise reason that
it doesn't need to be *parsed* again and again, just parsed once and then
executed as many times as necessary.

> so those statements are **never** checked 
> to determine what the new result will be.

  Why have such a stupid limitation? There's no reason nor need to.

> Instead you have to disconnect 
> the object definition, the if-else statements and the execution, so that 
> you 1) create an object with some static and some non-static transforms, 
> 2) render the first version, then 3) access those transforms you need to 
> change.

  How are you supposed to do step 3 without executing any code, like you
stated above?

  Even if it's done by executing some code, why would it be any more
difficult to apply a set of transformations to the object than it would
be to modify a set of transformations in the object? It's basically the
same thing (except that the former doesn't need to waste so much memory
needlessly).

> Yes, you could do that, sort of, now, but only via something 
> like macros, and that won't work in this case, since you can't simply 
> throw out the prior frames version, then reparse the macro.

  Again: Why do you think that the new SDL should have byte-compilation
and even JIT-compilation support?

  And also: How else are you supposed to change the object at each frame?

> You have to 
> have an already existing object, which you can make "some" adjustments 
> to.

  Without executing any code? How exactly?

  And again: Why would it be any easier to modify an array of transformations
than it would be to apply a set of transformations to the object?

> Macros don't do that. A Macro would **recreate** the entire object 
> each and every time.

  You are the only one talking about recreating objects here. I don't
understand why.

  I have been talking about applying sets of transformations to existing
objects.

  (And besides, it should be possible to create *new* objects and delete
existing ones at each frame, for memory optimization reasons.)

> **Every** method that currently exists in the SDL 
> works the way it does *precisely* because the assumption is that you 
> won't be changing and *existing* object, but creating a **new** one, 
> every single frame. The two implimentations are fundamentally different.

  No, the current SDL works like it works because of it's based on 10 years
old code. It's exactly why a rewriting is planned.

> If not, then please, explain to me how I am wrong here. Tell me how, 
> with something like an IK chain, you can **change** an object in the 
> sub-chain **after** it has already been calculated and added to a union. 

  By writing SDL code which applies transformations to it. In the exact
same way as your solution, but without the need for the useless arrays.

> I am willing to bet that if you **really** think about it, its not 
> possible.

  So in your opinion it is possible to change an array of transformations
at each frame, but it is not possible to apply a set of transformations at
each frame?

  So what is it that makes the difference?

> >   It would be perfectly possible in the current POV-Ray to change the
> > transformation matrix of an existing object if someone simply added the
> > proper syntax for it. (And that's exactly one of the reasons why the
> > whole new SDL is being discussed. To add easy support for such things.)
> > 
> Ok, fine. But how do you do that, without adding something that is at 
> least semantically the same as what I propose?

  It wouldn't be very much different, and that's exactly my point.
The only difference is that your "transformation array" is useless and
completely unneeded for this.

> And why, again, does it 
> make sense to store "every" transforms in some array, to be applied all 
> at once

  Eh, that's exactly what I am asking you. There's no need for any array.

>, instead of maintaining an array of "existing" transforms 
> applied the the object, then only adding to, changing or deleting the 
> specific on you need to?

  There's no need to do it that way. That's only one possibility of doing
it. A possibility seldom needed or used. That's not how rendering works
in general out there.

> >   You *apply* transformations in the SDL code. You don't *store* them
> > (not as individual transformations anyways). That's because the individual
> > transformations are already "stored" in the SDL code itself. Why do you
> > need to store them in two places?
> > 
> Yes, they don't have to be. The can be calculated as you go, but they 
> still have to then be **applied** individually, regardless of if you 
> plan to repeated apply the same initial translate, then a changing 
> rotate, then another translate, or something. It might not be "stored" 
> any place, but you are still wasting code to do something that is 
> functionally the same thing.

  It's not "wasted code". Your solution is to first write code to initialize
the array for the first time and then at each frame run some other code
which modifies the array.
  The general solution (used often eg. in OpenGL) is to write just one
routine which applies the transformations (possibly depending on some
variables, etc) at each frame. This can actually save coding because
basically you are only doing the initialization step. (If the object
is not modified between frames then running this code can be skipped,
of course.)

  (Of course if you really *want* to have an array which you modify and
then apply, you can. However, you are not forced to use one.)

> But yes, if you want to do it that way, you 
> could. I suppose, in that sense my idea just means that you have access 
> to what ever "initial" state you started with

  The problem with your solution is that it hard-codes one data container
which is not very flexible. And what makes it worse is that there just
isn't need for such a data container.

> in a way that is more 
> accessible than just returning the matrix and then wondering how the 
> hell you got to there

  You don't read a transformation matrix and try to modify it. You reset
the transformation matrix and apply the transformations to it. That's
standard procedure.
  The chain of transformations is already "stored" in the very code
which applies those transformations. In your proposed solution this
chain of transformations would be located at two places: In the array
and the code which initializes the array. This is redundant and unneeded.

  (Besides, related to the earlier discussion in this post, even having
such arrays doesn't at all solve the problem of how to transform sub-objects
in a deeply-nested union.)

> So, OK, I admit, what I 
> propose may not be strictly necessary, it might be useful some times, 

  That's exactly the point: *Sometimes*

  The thing is, if *sometimes* you would need such an array, you can
create one. There could even be some kind of library to aid you doing
this. But the point is that this specific solution should not be forced
on the user since it's not necessary.

  This kind of specific solution should not be something done in the
core code. The core code should have a more generic solution.

> >   Let me see your suggestion about the new SDL code which modifies the
> > "transformation array" at each frame.
> >   My answer is that it's the exact same thing, but without the transformation
> > array. Simply apply all the transformations to the object at each frame.
> > 
> Well, I think I am thinking more in terms of the data end, rather than 
> the program end. I am thinking in terms of, "Automatic application of 
> known transforms.", you are thinking more in terms of, "Manual 
> application of any needed transforms."

  There's nothing stopping you from automatically applying transforms
to the object from some data. Your "array" solution makes absolutely
no difference in this.

-- 
                                                          - Warp

Post a reply to this message